Ordered execution processes operations sequentially, stopping at the first error, while unordered execution processes in parallel, continuing even if some operations fail
In MongoDB bulk operations, the ordered parameter determines how the database processes the batch of write operations. This setting fundamentally affects both performance and error handling behavior. When set to ordered: true (the default), MongoDB executes operations sequentially in the order they are provided. If an operation fails, the entire bulk operation stops immediately and returns an error, with no remaining operations processed. When set to ordered: false, MongoDB can execute operations in parallel (or in any order), and even if some operations fail, processing continues with the remaining operations .
Ordered execution provides predictable, sequential processing of operations. This is particularly valuable when operations have dependencies—for example, when you need to insert a parent document before inserting its child documents that reference it. In ordered mode, if any operation fails, MongoDB returns an error and does not execute the remaining operations, preserving data consistency when operations are interdependent . However, this sequential processing can be slower for large batches because operations cannot be parallelized, and network round trips may be required for each operation.
Unordered execution prioritizes throughput over strict ordering. MongoDB can execute operations in parallel, which can significantly improve performance, especially for large batches. When errors occur, MongoDB continues processing remaining operations, providing a partial result that includes both successes and failures . This is ideal for scenarios where operations are independent and you want to maximize throughput, such as inserting large datasets or performing bulk updates where occasional failures are acceptable and can be handled separately.
Dependent operations: When operations must execute in a specific sequence, such as creating a document before referencing it in another operation .
Data integrity requirements: When a failure in any operation should prevent subsequent operations from executing to maintain consistency .
Debugging and testing: Ordered execution makes it easier to identify exactly where a failure occurred and ensures the batch stops at that point .
Regulatory or audit requirements: When you need guaranteed execution order for compliance purposes .
Maximum throughput: When operations are independent and you want the fastest possible execution, especially for large datasets .
Resilient data loading: When loading data where some failures are acceptable and you want to continue processing regardless .
Parallel processing: When you can benefit from MongoDB's ability to execute operations in parallel across different shards or collections .
Real-world example: Your earlier scenario of scraping 1 million products—if one product fails to upsert, you still want the other 999,999 to be processed .
Performance testing: Studies show that unordered operations can be 5-10x faster than ordered for large, independent workloads .
The performance difference between ordered and unordered can be dramatic. In a sharded cluster, unordered operations allow MongoDB to send write operations to different shards in parallel, dramatically reducing total execution time . Even in non-sharded environments, unordered operations can achieve higher throughput because they avoid sequential processing bottlenecks. However, this comes at the cost of losing execution order guarantees and potentially receiving partial results that require additional handling.
Error handling differs significantly between the two modes. With ordered execution, the operation stops at the first error, making it clear where the failure occurred but potentially leaving many operations unprocessed . With unordered execution, you receive a result object containing an array of write errors, allowing you to identify and retry failed operations while acknowledging successful ones. This makes unordered mode particularly suitable for batch processing pipelines where idempotency can be designed into the operations.